Add support for Manifests with No Installers#6157
Add support for Manifests with No Installers#6157Trenly wants to merge 7 commits intomicrosoft:masterfrom
Conversation
This comment has been minimized.
This comment has been minimized.
|
Tagging @hackean-msft as I'm not sure if the install validation would handle this cleanly currently or not; I believe it may be likely that the validation pipeline would need to skip installer validation for |
installer type. At first I thought you were introducing a whole new manifest file type, which seemed overkill. This is definitely a design level thing before I'm going to look too deeply at 45 files 😄 I could imagine @denelon wanting to consider this a lot more. Thinking things like "We shouldn't show uninstallable packages in search results", which would require index work (he already wants a bitrack that I will have to defend every bit on to save bandwidth). |
Yes, Installer type :) Definitely need to consider design first which is why I created this as draft to discuss before I ask anyone to review this beast I know there is a separate isse out there (#823) for filtering on installer method / installer type, so thought the work for hiding from search would fit in well with that work if / when we get to it - and I purposely made it so a custom message could be specified so that if a user does get an un-installable package (say for example, it was moved to a different package identifier, or removed by publisher request) then there would be a nice clean message. Looking forward to denelon's feedback :) |
|
This is an approach I hadn't considered before. On the surface I like it because it's not a new "filetype" requiring some new schema. It might be strange to require an InstallerURL for something that shouldn't be installed so we might need to think about that field, but preserving things like the SHA256, product code, upgrade code is useful for correlation. I'm just not sure about reasoning over a PR to modify something with a known installer type. I'm also not sure we would accept PRs with this installer type unilaterally. There are lots of implications to reason over. |
|
@denelon - this is buit in a way that wouldn’t require a URL; in fact, it prohibits a URL. |
Thinking through this, validation could add Validation-No-Executables and be waivered, forcing MSFT review for each instance |
3 participants
Summary
This PR introduces support for the
noinstallerinstaller type (manifest version 1.29.0), which allows publishers to declare packages that have no downloadable installer. This enables WinGet to correlate against already-installed software even when no installation artifact is available — useful for system components, pre-installed software, and packages distributed through channels outside of WinGet. This also acts as a way to notify clients that a version has been removed for a specific reason, a package has been removed for a specific reason (CVEs, publisher request, moved to a new identifier, etc.), while still providing tools over at winget-pkgs like the duplicates checker a way to enforce removed packages by SHA.What's New
NoInstaller Installer Type
Publishers can now declare a manifest with
InstallerType: noinstallerto indicate that a package exists and is recognized by WinGet, but has no installer to download or run. WinGet will correctly handle these packages across theinstall,show, andupgradeworkflows.Installer Availability Message
A new optional manifest field,
InstallerAvailabilityMessage, allows publishers to provide a human-readable explanation when an installer is unavailable. This message is surfaced to the user in place of the generic fallback message, giving them actionable context (e.g., a link or explanation of where to obtain the software).This change may require changes to the validation framework, which is why the PR is being created as draft
Microsoft Reviewers: Open in CodeFlow